Many organizations realize tremendous efficiencies by exchanging business documents with their trading partners via an electronic communication method known as electronic data interchange (EDI). Common documents exchanged include, among others, purchase orders (PO), invoices, advance ship notices (ASN), bills of lading and payment status documents.
There are a number of EDI standards that specify the encoding format of EDI documents, including mandatory information, optional information and document structural information. Examples include, but are not limited to, ANSI ASC X12, UN/EDIFACT, TRADACOMS, GS1 EDI. EDI documents may be exchanged using a variety of technologies such as FTP, telnet, e-mail, HTTPS, AS1, AS2 and others.
In general, trading partners wishing to participate in direct (point-to-point) EDI exchanges with each other must agree on a specific EDI standard and version to use and transmission method so that the trading partners' computer systems can exchange EDI documents. For example, trading partners may limit data types that can occur in certain fields. Thus, the EDI documents exchanged between trading partners have an EDI-encoded format known to both trading partners and are exchanged using an agreed upon protocol. An organization with several trading partners may have to acquire multiple hardware and software systems to participate in direct EDI exchanges with the trading partners if the trading partners use different EDI standards or transmission methods.
To address some of the deficiencies of direct EDI exchanges, organizations with a number of trading partners may find it more convenient to use an EDI network service. An EDI network service is a service, typically provided by a third party computer system that acts as an intermediary between trading partners. An EDI network service may support a large number of EDI formats and transmission methods. In some cases, the EDI network service can translate the EDI document between EDI formats prior to routing it to the second trading partner.
The underlying EDI standards limit the convenience of EDI, even when done through an EDI network service. One issue with EDI is that the relatively small number of document types supported by EDI standards or implemented by trading partners limits the types of information that can be exchanged between trading partners using EDI. In particular, an EDI standard as implemented by a set of trading partners may not support the trading partners alerting each other of potential exceptions—that is, situations in which an exchange will not occur within the requirements or expectations of the trading partners.
An example of this shortcoming can be seen with respect to late and early delivery of items ordered in EDI purchase orders. In a typical EDI exchange, a first trading partner will send an EDI PO to a second trading partner ordering items and specifying a requested delivery date. When the order is ready to ship, the second trading partner sends an EDI ASN that includes information about how many items are being shipped, physical characteristics of the items, number of packages, mode of transportation, when the order will be shipped or other information as specified by the EDI format being used. However, there may be no EDI document that the second trading partner can send to the first trading partner to indicate that a delivery will be late or early before sending the ASN prepared at the time the shipment is ready. For organizations implementing just-in-time manufacturing, both early and late delivery of components from a trading partner can disrupt the manufacturing process and have significant deleterious effects throughout a supply chain.